Smartcards are rapidly becoming a favored way to transport and communicate personal information securely and reliably. Smartcards assume the general size and shape of a conventional credit card but include data processing and storage circuitry that allows them to receive, process, store and transmit information. By virtue of their size, information-carrying capacity and security, Smartcards are destined for use in financial (e.g., banking) transactions, official identification and healthcare delivery, among other things. International Standards Organization (ISO) Standards 7810, 7816/1 and 7816/2 specify the physical structure and hardware and software architecture of Smartcards and are incorporated herein by reference.
Smartcards receive and transmit information by being coupled to a “cardbus.” ISO Standards 7816/1 and 7816/2 also specify the structure and communication protocol(s) of cardbuses. Since security is touted as one of the hallmarks of Smartcards, the above-referenced standards provide for a reasonably high level of security of data crossing a cardbus. In addition, Deutsch Telecom has created a certification process, called “B,” that establishes a security level for Smartcard terminals as a whole. Compliance with B1 affords a distinct competitive advantage.
Personal computers (PCs) can advantageously host Smartcard interfaces so they can act as multifunction terminals with respect to Smartcards. As a Smartcard terminal, a PC could, for example, enable point-of-sale (POS) financial transactions to be made or medical information to be taken from, or given to, a patient. To enable a PC to act as a Smartcard terminal, the host PC must be provided with a suitable hardware adapter. A suitable adapter contains a Smartcard controller and typically assumes the physical form of an expansion card coupled to the host PC's Peripheral Component Interconnect (PCI) bus.
While the PCI bus presents a nearly universal, reliable, wide, fast, open-standards bus suitable for communication with a Smartcard controller, its security does not rise to the level required for Smartcard communication, and particularly for compliance with B1. The security issue arises when the Smartcard controller is initialized. To understand the problem, one should understand how a Smartcard controller would be initialized in a host PC.
A Smartcard controller contains flash memory. During initialization, firmware for driving the controller is caused to be loaded from the PC's hard drive into Smartcard controller's flash memory. Then, in a separate action, a Smartcard driver is caused to be loaded from the PC's hard drive into the PC's main memory. An application running in the PC can then communicate with the Smartcard driver; the Smartcard driver communicates with the firmware; and the firmware communicates with a Smartcard via the Smartcard controller. The communication path is reversed for data transmitted from the Smartcard back to the application.
The security hole exists because the firmware must be loaded across the PCI bus, which as stated above is non-secure. The Smartcard controller is rendered non-secure as a result. A hacker could change the firmware before it is loaded into the flash memory and thereby create a “back door” into a financial, medical or insurance information network. To increase security, the firmware could, of course, be installed into the flash memory when the Smartcard controller is manufactured and never changed thereafter. However, that significantly impairs the flexibility and utility of the controller and is therefore unacceptable.
Accordingly, what is needed in the art is a way to improve the security of Smartcard controller initialization in a PC such that the security of the firmware loaded into the Smartcard controller is reasonably guaranteed. More specifically, what is needed in the art is a way to provide a level of security over a PCI bus that meets or exceeds B1.